先看結果如下圖，MySQL資料庫的尖峰效能，CPU使用率由100% 分二階段降低，最終至使用率低至 15%!，到底我做了甚麼? 接著我會慢慢告訴你。

背景

首先工商時間一下，我司使用Azure已經多年，開發的 SaaS 服務名稱是『E樂堂』，主要是提供客戶租用後，可以快速建立線上課程的教學網站，免除客戶自行建立主機、管理系統的麻煩! 服務已經運行超過 3年，客戶的課程包羅萬象，例如：
銷售心理學課程的軒言文創
銷售管理類課程的鼎新電腦知識學院
Epson機械手臂經銷商與客戶訓練
動畫軟體教學的影視學院

如果看官有任何可以教的，不管是錄製影片，還是錄製音頻，甚至直播，都可以運用E樂堂，收費或免費進行教學。會看這一篇的大概是程式設計師或DBA吧! 這類型課程倒還沒有喔! 有興趣的話，歡迎與我司聯絡，電郵是 sales@vcube.tw。

開始吧

等一下，我想有人會問，為什麼我們會用 Azure MySQL (正確但是繞口的中文名稱是: 適用於 MySQL 伺服器的 Azure 資料庫)，而不採用 Azure VM 自己安裝 MySQL?

當時我們覺得， Microsoft 既然商轉 Azure MySQL了，肯定比我們自己安裝，系統要更穩定，效能調教要更好，讓我們可以 focus 在核心業務開發上，事實上，穩定是沒有問題，可是初期預算關係，我們選用 Basic Layer，沒有注意到的是 Basic Layer 無法直接升級到 General Purpose (二者以同樣的 2vCPU，價差一倍)，導致我們有點小崩潰!

但是還好，當時營運初期，資料量還沒有太大，剛好一年前 Azure MySQL RI (保留容量) 也開始提供，價格大約是一般算法的一半，就直接轉移到 General Purpose 4vCPU等級了!

既然升級到 4vCPU，理論上應該資源充足，高枕無憂了吧，就在2020年10月，第一次收到 Azure 的效能建議，內容是:

增加伺服器參數的值：tmp_table_size、max_heap_table_size
在適用於 MySQL 的 Azure 資料庫上以最佳方式調整您的工作負載

不錯喔，Azure 真的會建議我們對 Azure MySQL 調整參數，優化效能，果然當初選擇 Azure MySQL 是對的! 按照其建議，做了參數調整，將建議的參數值都調整到最大；隔沒有幾天，相同的建議又出現了，我已經調整到最大了，還要我怎麼樣! 經過 Microsoft 技術支援詢問，工程師說既然已經開到最大，那也就沒有甚麼可以做的了! 好吧，不了了之…
接下來，我們就觀察 MySQL 的資源指標，就像上圖，很明顯，每天從早上10點開始，CPU使用率開始扶搖直上，最終就會接近 100%，那段時間，我們團隊每天緊盯著，心情七上八下，但是似乎對於我們的服務影響看不太出來，不過作為 SaaS 服務可不能這樣搞，還是要找出來原因啊，真的是用量大的原因嗎? (可是收入沒有扶搖直上啊…) 假如真的是用量太大，那只能再升級，但是下一級距 8vCPU的RI就直接跳到約一年15萬，這…!

經過一段時間的觀察，不管透過 slowlog，還是 MySQL Workbench，我們都發現了一個相同處，有一個 select query 數量非常多! 跟 RD 討論這個 select，語法本身非常簡單，而且是最底層、最基本要用的，改善空間有限，怎麼辦?

我們只好從資料庫參數下手，研究看看 Azure MySQL 有哪些參數是跟效能有關的，作為噴錢之前的最後掙扎!!!

不騙你，我們是一個個參數 google，看看是不是可能對於效能可以提升，但是畢竟這是 production 資料庫，每一次的調整我們都七上八下，但是不在 production 調整，根本看不出效果啊，硬著頭皮幹吧!

終於皇天不負苦心人，讓我們試到一個參數: thread_handling
預設值是 ONE-THREAD-PER-CONNECTION
可以調整為 POOL-OF-THREADS

不管從字面上，或是 google 的結果，感覺都是 POOL-OF-THREADS 比較優啊，為什麼預設值不是他! 這個參數調整因為要 reboot 後才會生效，所以我們等到半夜再做，隔天就看到了效能圖的 (1)，真的有效喔! 雖然峰值只有下降了一點點，但是我們興奮之情溢於言表!

再接再厲，我們終於找到一個決定性 (2) 的參數，讓 CPU 使用率遽降至 20%以下，這個救命參數就是: query_cache_type

預設值是 OFF，可以調整為 ON 或 DEMAND，調整為 ON 之後，我們崩潰了! 這個神一樣的參數，就這樣讓我們得到救贖!

研究這個參數時，爬到的文有人寫有用，有人不建議，我們著實掙扎，大致上說的是，select query 執行後會放到 cache，如果有重複相同的 query，MySQL就直接取用 cache，不再進行 query，所以不建議的人是說，如果資料庫異動多，結果 query 反而會降低效能，因為要先比對 cache，而我們的這個 table 就是沒有異動，只是 query 比對，所以造成這麼巨大的效能提升!

結論

RD 工程師經驗非常重要，DBA 絕對也是!
我司的RI降級，再度省下一半的費用...
老闆也因此...喔! 我就是老闆，沒事。